In traditional data storage systems, such as databases, consistency is usually achieved by a data locking mechanism to prevent data from being corrupted or invalidated when multiple users try to write to the same data. When a lock of the data is acquired for a transaction, the transaction has access to the locked data until the lock is released. Databases support the XA (X/Open XA) architecture and XA transactions, which are transactions that consist of multiple operations that access resources. For example, a banking application may conduct an XA transaction that consists of two operations (1) deduct money from a first bank account and (2) add money to a second bank account. The second account may be in another database system. Typically, either both of the operations relating to the XA transaction will be permanent, if successful, or none of them will occur. The XA standard uses a two-phase commit (2PC) protocol to ensure that all resources enlisted within a transaction either commit or rollback to a previous state. The first phase is preparation. If preparation is successful, the second phase of commitment can be initiated.
A pessimistic locking approach typically acquires locks with each write operation of a transaction. For example, a lock may be acquired when the first bank account balance is changed and a lock may be acquired when the second account balance is changed. In an optimistic locking approach, locks are usually not acquired until a transaction is being completed. For example, the transaction can change the account balances for the two bank accounts within its own transactions scope, even if the accounts are accessed by another transaction at the same time without acquiring a lock. In a typical distributed hybrid optimistic-pessimistic locking approach, local locks may be acquired as a transaction progresses and remote locks may be acquired when a transaction is prepared for a commitment.
Generally, when a database utilizes a pessimistic or a hybrid locking approach, the database throughput is greatly reduced because the database waits to acquire a lock for each operation for one transaction and waits until a lock is released to allow another transaction access to the same data. In a database, the transaction data is maintained by a single operating system process. Thus, even when a lock is acquired using optimistic locking, for example, during the commit phase of a transaction, other transactions are still not able to access the locked data. For example, if a first transaction has acquired a lock on data in the database and a second transaction wishes to access the same data, the second transaction waits until the lock is released because the data is not available elsewhere.
Data grids are an alternative to databases. A data grid distributes data across multiple operating system processes. The operating system processes can run an instance of a data grid application and can use a distribution algorithm to determine which processes in the data grid have the data for a transaction. Each process can own data and allow other processes access to the data. Unlike a database, the distributed data of a data grid removes single points of failure. Data grids that support XA transactions typically implement a pessimistic or hybrid locking approach and usually face the same shortcomings of having a greatly reduced throughput. Even if a data grid implements an optimistic locking approach, the data grid is usually not operating efficiently because the data grid keeps copies of the data for the optimistic locking in the same place where the data is actually located. Storing copies with that in the same location as the actual data may involve an increased number of expensive remote calls when the same data is accessed repeatedly in the scope of a transaction.